NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/6511

Internet Message Format | 1996-08-05 | 9.4 KB

Path: news.NetVision.net.il!news
From: Jack <[e-mail]>
Newsgroups: comp.sys.amiga.programmer
Subject: Re: 680X0 -> PPC translator?
Date: Fri, 29 Mar 1996 09:10:35 -0800
Organization: NetVision LTD.
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: ts002p9.pop4a.netvision.net.il
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.0b6a (Win16; I)

Hi Volker, well i'll try to keep the lines shorter this time
so you'll be able to read the text more conveniently and who
know. you might actually be convinced that 680x0 -> PPC is possible. ;-)
well let's do battle....;-)
Volker Barthelmann wrote:
>
> Avi L. ([e-mail]) wrote:
> : Volker Barthelmann wrote:
> Once an external function is called almost all information becomes useless,
> because You don't know what memory it changes.

ok, but i'm assuming the library is already PPC translated so if
it does any self-modifying tricks, the code will already be translated
and in the correct size. all i care about is that point anyway, if it
uses the area as a data region then i don't care what it does with it
since the data is the same size regardless of the processor used to
manipulate it.

>
> : if you perform careful analysis of the pointers, and that means following the changes made
> : to them by the program, you CAN know in which context they are being used and act
> : appropriatly. for example:
>
> Perhaps You can perform this analysis. An algorithm can't.

why the hell not, if i can understand assembly source code,
the machine can understand machine code right?!
and we already know what we're looking for, (variations in
memory segments which are later used for code execution).
if you know the machine op-codes well enough writing an
algorithm is pretty much straight forward.
>
> : call _malloc ; let's say register a1 holds the returned address.
> : move a1,xyz(a7) ; store it in some variable, noting the current value of a7.
>
> Of course You can have a structure holding all Your variables. Now You pass
> the address of this structure to an external function that writes some
> values into it and You lost.
>

i don't seem to care about that, get it through your head, i'm NOT
going to intervene with what the program does with any memory area,
just as long as this memory area is not later being used for code
execution. then, and only then will i have to turn to all the locations
where that pointer could have been assigned and then change the size
argument which i already know to the appropriate sizes, once i figure
out that the area is code, i will perform a well defined series of actions
to resolve ALL dependecies related to that area, including size, write loops etc.

> : what i mean is, you use your own value of a7 with an initial value of 0 and follow the
> : changes made to it resetting it to 0 on assignments. that way you don't need the actual value
> : of a7 for knowning to which variable it refers to. now you know the address of the pointer to
> : the allocated block i just malloc()'ed so you can know how it's being used later, eg. code or data.
> : and bear in mind that all memory allocation routines call evantually AllocMem() function so you
>
> There are several memory allocating functions or other functions You can't
> know anything about.

then you take into account all of the various SYSTEM functions which allocate
memory (there aren't many of them) and proceed as normal.

>
> : have the instruction address of where exactly the memory region was allocated and so you can change
> : the size argument for the function if that memory area is later used for self-modifying code.
> : also you have to follow any loops which do writes to the area cuz these might be the sections
> : that copy code into that area and so you have to make the adjustments so that they loop
> : according to the translated code size.
>
> You would have to adjust EVERYTHING that is in any way dependant on the code
> size! How are You going to do this?

all you have to look for is where it was allocated and where it is copied,
assuming you're copying code that is. quite easily done if you follow the
change made to that pointer while 'running' through the program's logic.

>
> : > : from some outside source, such as malloc(), then you don't have it obviously but that being said
> : > : doesn't imply it's impossible to figure out in which context the address is being used (ie code
> : >
> : > Easy??
> :
> : yes easy, cuz as i said you know where it was allocated and you can change the appropriate
> : argument.
>
> Er..have You ever really programmed anything with data flow analysis?well actually yes, i did, although it wasn't anywhere near as complex
as the problem we're talking about.

>
> : > And in many programs You won't find any call to e.g. AllocMem with this
> : > size at all, because the program uses its own memory-pool-routines.
> : > Etc. etc...
> :
> : but then again it must have allocated the master pool from which it sub-allocates memory from
> : and besides it must pass that allocator the required size, so you can change it if that segment
> : is later used for code, you know the size of the copied code after all and if the size passed to
> : the function is sufficient for the translated code then you don't have to do anything otherwise
> : change it.
>
> As the size of the sub-allocated memory changes You may have to completely
> rewrite the pool-allocator, because it may depend on the allocations being
> of certain sizes or a multiple of a certain sizes etc.
> To do this the translator would have to completely understand the allocator
> and this is impossible.

what???? all you have to do is request the allocator for more memory, no need
to change anything in the allocator itself. the only possible problem i see here
is when the size argument would not be passed through the stack but by some global
variable the program sets just before calling it, but even that is possible to solve
by looking at a few calls to that allocator and discern the calling convention used.
surely the allocator is used more than once in the program.

>
> : > It's not unfounded, but I've thought about some things.
> : > There are much simpler similar problems that are AFAIK proven to be
> : > undecidable.
> :
> : care to elaborate on this please.
>
> I think most standard data flow problems can only be approximated, but exact
> solutions (which would be needed by Your approach) can not be found.
> AFAIR I read somewhere that this was proven for some cases, but unfortunately
> I don't remember where it was.

granted, you're right about that not all solutions are clear cut but when it comes
to exact sciences such as computer-science then i would disagree, especially
since the problem we're dealing with isn't related to any human logic, that
field even in computer-science hasn't been fully explored and understood yet.
no, the only major problem is self-modification of the program otherwise you
translate the code 1:1.

>
> : what the hell does recursion have to do with anything, it simply calls the function from within
> : itself, so what??? if you follow the changes to a7, then you'll always point to the right address,
> : remember that auto-variables don't exist cuz the programs is not running and so all references are
> : are register (a7) indirect and so nothing really matters, you use registers not absolute addresses.
>
> You seem to think that every program uses variables and registers in the same
> way like a certain compiler. This is not true.

a variable is just another location in memory, the compiler has nothing
to do with its implementation, HUH.

> : gimme one example where i would fail to translate that. believe me it should fine.
>
> I gave several examples. The discussion is rather pointless as long as You
> just say 'I keep track of this' and 'adjust that according to xyz' etc.
> Of course it's possible to rewrite a program to PPC, but You have to show
> that this can be done by an algorithm and this is a different story.
>well saying that often doesn't mean it's wrong and it would be foolish not
to explore every suggested solution. if you are so convinced it is not
possible then surely you can provide me with a concrete proof to undermine
my theory, can't you?! remember the burden of proof lies on my shoulders
cuz i claim something is possible, so you have to give me an example
i can't solve with my theory.

> Once You describe Your algorithm I will happily give You an example.

the algorithm mainly revolves around self-modification, otherwise it's
a simple translation of code instructions. and my algorithm, though wasn't
presented in a flow-chart, is presented by words. that doesn't mean it's impossible
to write an actual algorithm in a true sense of the word.

> But believe me it will never ever work for anything more than some special
> programs. Data flow analysis can be useful for many things, but there are
> severe limitations and Your approach would practically have to 'understand'
> the program and completely rewrite it.
> This is completely absolutely impossible. No chance. Never. Won't work.

AH, but that's what i had said before, and really, it is possible, stop being
so passimistic, and start being constructive. besides, most application programs
do conventional programming, so even if it's limited to them, it still has
great value.

Avi Lev.